Method for minimizing the risk and exposure duration of improper or hijacked dns records

ABSTRACT

Provided is a method for assigning a time-to-live (“TTL”) value for a domain name system (“DNS”) record at a recursive DNS server. The method comprises obtaining, from a client, the TTL value for the DNS record; and storing, in a memory of the recursive DNS server, the TLL value, an identifier of the client, and the DNS record.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationtitled, “METHOD FOR MINIMIZING THE RISK AND EXPOSURE DURATION OFIMPROPER OR HIJACKED DNS RECORDS,” filed on Jul. 31, 2020 and havingSerial No. 16/944,607, which is a continuation of U.S. patentapplication titled, “METHOD FOR MINIMIZING THE RISK AND EXPOSUREDURATION OF IMPROPER OR HIJACKED DNS RECORDS,” filed on Oct. 21, 2015and having Serial No. 14/919,270. The subject matter of these relatedapplications are hereby incorporated herein by reference.

FIELD

The present disclosure relates to the field of Domain Name System(“DNS”) resolution.

BACKGROUND

A description of the ways in which the Internet is intrinsicallyorganized can be helpful in understanding the challenges related toefficiently monitoring and rating the traffic for particular web siteson the internet.

The process of establishing a web site on the internet typically beginswith a registrant registering a specific domain name through aregistrar. The registrant is typically an individual or organizationthat identities a domain name, such as “example.com”. The registrantcontacts a registrar to process the name registration. The registrarthen sends the necessary DNS information to a registry. A registrar maymaintain a database containing additional customer information beyondthat which is sent to the registry.

The registry receives DNS information from registrars, inserts thatinformation into a database and propagates the information on theinternet so that domain names can be found by users around the world.

In general, the DNS is the part of the Internet infrastructure thattranslates human-readable domain names into the Internet Protocol (IP)numbers needed to establish TCP/IP communication over the Internet. Thatis, DNS allows users to refer to web sites, and other resources, usingeasier to remember domain names, such as “www.example.com”, rather thanthe numeric IP addresses, such as “123.4.56.78”, assigned to computerson the Internet. Each domain name is made up of a series of characterstrings (labels) separated by dots. The rightmost label in a domain nameis known as the “top-level domain” (TLD). Examples of well-known TLDsare “.com”; “.net”; “.org.” etc. Each TLD supports second-level domains,listed immediately to the left of the TLD, e.g. the “example” level in“www.example.com”. Each second-level domain can include a number ofthird-level domains located immediately to the left of the second-leveldomain, e.g. the “www” level in “www.example.com”. There can beadditional level domains as well, with virtually no limitation. Forexample, a domain with additional domain levels could be“www.photos.example.com”.

Additional non-domain information may be included in a Uniform ResourceIdentifier (“URI”) structure that includes the domain name. For example,a “path” part is a sequence of segments (conceptually similar todirectories, though not necessarily representing them separated by aforward slash (“/”). This information may be included immediately to theright of the domain name, such as the “blog” in “www.example.com/blog”,and may be used by a server or other receiving device to identify anddeliver specific content or run particular code. Other examples ofnon-domain information may include queries and fragments, the specificsof which are understood by those of ordinary skill in the art and arenot discussed in detail herein. Combinations of this information may beincluded in web page hyperlinks that navigate a user to another sectionof the same page or to another web page that may be part of the same, ora different, domain.

Related domain names, and content, may be organized in a hierarchical,or nested, manner, such as “www.example.com”; “www.blog.example.com”;“www.example.com/blog”; or “blog.example.com” etc., each with adifferent significance. Such related domains need not share similaritiesin the actual IP address to which the various domain names resolve to,in this regard, part of the domain name may signify a particular serverwhich is desired, for example, “mail.example.com” and www.example.com”may resolve to different servers, with different functions, for the samesecond-level domain.

The above registration and structural aspects of the internet are thenused by end-user applications to find specific resources on the internetby using the DNS resolution process. Aspects of the DNS resolutionprocess are discussed below to aid in an understanding of the subjectmatter of the present application.

The responsibility for operating each TLD (including maintaining aregistry of the second-level domains within the TLD) is delegated to aparticular domain name registry. The registry is responsible forconverting domain names to IP addresses (“resolving”) through DNSservers that maintain such information in large databases, and operatingits top-level domain. The DNS stores IP addresses and domain names,facilitating service to addresses in TLDs, such as .com, .net, .edu, and.tv. Resolving is the process by which domain names are matched withcorresponding IP numbers. Resolving is accomplished by a combination ofcomputers and software, referred to as name servers, which use the datain the DNS to determine which IP numbers correspond to a particulardomain name. The following general definitions will be used herein.

Resolve: To translate domain name to IP address.

Resolver: A computer that can respond to a query in order to resolve adomain name.

Name server: A computer receiving queries and answering them directly orvia a resolver against other name servers.

Subnet: A group of IP addresses sharing an initial sequence of octets ofthe IP address.

Internet domains can be divided to groups according to their TLD suffix(e.g., .com, .net, .co.uk ...) with different registries responsible foreach of them. A single registry may be responsible for several of thesegroups, such as the VeriSign registry which is responsible for .com and.net domains.

The DNS is implemented as a distributed database system, which uses theclient-server model. The nodes of this database are the name servers.Each domain or subdomain has one or more authoritative DNS servers thatpublish information about that domain and the name servers of anydomains subordinate to it. The top of the hierarchy is served by theroot name servers, the servers to query when looking up (resolving) aTLD.

The DNS distributes the responsibility of assigning domain names andmapping those names to IP addresses by designating authoritative nameservers for each domain. Authoritative name servers are assigned to beresponsible for their particular domain.

In theory a fully qualified domain name may have several name segments,(e.g. www.one.type.example.com). For querying purposes, the name segmentis typically interpreted by segment, from right to left. At each stepalong the way, a corresponding DNS server is queried to provide apointer to the next server which it should consult.

Because of the huge volume of requests generated by DNS, the resolutionprocess also allows for caching (i.e. the local recording and subsequentconsultation of the results of a DNS query) for a given period of timeafter a successful answer. How long a resolver caches a DNS response(i.e. how long a DNS response is considered valid) is determined by avalue called the time to live (TTL). The TTL is generally set by theadministrator of the DNS server handling the response. The period ofvalidity may vary from just seconds to days or even weeks.

Based on the DNS structure, as well as the caching function, there aretwo classifications typically applied to the name servers, authoritativeand recursive (caching). An authoritative name server is a name serverthat gives original, definitive answers (“authoritative” answers) to DNSqueries. Every domain name must be assigned a set of authoritative nameservers that are responsible for resolving the domain name.

As indicated above, the DNS also uses recursive cache servers, whichstore DNS query results for a period of time determined TTL of thedomain name record in question. Typically, such caching DNS servers alsoimplement a recursive algorithm to resolve a given name starting withthe DNS root through to the authoritative name servers of the querieddomain. Internet service providers (ISPs) typically provide recursiveand caching name servers for their customers. In addition, many homenetworking routers implement DNS caches and recursors to improveefficiency in the local network.

DNS “stub” resolvers are also known that essentially operate as acache-less application to resolve DNS names into IP addresses. The DNSstub resolver forwards DNS queries to the DNS server configured for theworkstation (or server) and returns the DNS server’s response to therequesting software. If a stub resolver queries a caching nameserver fora record that is being held by the caching server before the TTL hasexpired, the caching server will reply with the cached resource recordrather than retrieve it from the authoritative name server again.

DNS resolvers can cache results for a period of time up to the TTL ofthe DNS record that was retrieved. In order to handle invalid records(due to errors or malicious activity), most resolvers offer a mechanismfor cache flushing to evict invalid records from their cache andtherefore retrieve updated records. Operationally, it is often difficultfor organizations systematically flush the cache of all of theirinternal resolvers. In addition, many organizations or individuals maynot be aware of an issue with an invalid record and will not know toexecute a cache flush. As a result, the invalid record can last for sometime, possibly exposing them to malicious servers.

TLD attacks are relatively easy to perpetrate due to the nature of DNScommunications. That is, DNS communications are typically sent via theUser Datagram Protocol (UDP). UDP is a simple communication protocol fortransmitting small data packets without a connection handshake,acknowledgment, ordering, or error correction. The low processingoverhead of UDP makes it useful for streaming media applications such asvideo and Voice over IP, and for answering small queries from manysources, such as in DNS resolution. Unfortunately, these same propertiesallow attackers to use DNS resolution for nefarious purposes. BecauseUDP is connectionless, an attacker can “spoof” the source address (thatis, forge a false source IP address in the IP packet such that the DNSserver sends the query response to a third party) without having toworry about completing a connection handshake, resulting in the DNSserver sending responses to a machine that never sent a query. Moreover,the query message can be relatively small (under 512 bytes) while theresulting response can be substantially larger due to large numbers ofresource records in the response. This allows an attacker to hijack aDNS server to magnify an attack. DNS queries and response may also besent over stateful Transmission Control Protocol (TCP), which exhibitssimilar vulnerabilities that can also be managed using embodiments ofthe invention disclosed herein.

SUMMARY

In accordance with aspects consistent with the present teachings, amethod for a method for assigning a time-to-live (“TTL”) value for adomain name system (“DNS”) record at a recursive DNS server is provided.The method can comprise obtaining, from a client, the TTL value for theDNS record; and storing, in a memory of the recursive DNS server, theTLL value, an identifier of the client, and the DNS record.

In some aspects, the method can further comprise obtaining, from theclient, a policy to be applied to the DNS record to control how the DNSrecord is processed.

In accordance with aspects consistent with the present teachings, amethod for answering a domain name system (“DNS”) request at a recursiveDNS server is provided. The method can comprise obtaining, from aclient, a DNS query for a DNS record; determining, by the recursive DNSserver, that an answer to the DNS request is not found in a memory ofthe DNS recursive server; providing, by the recursive DNS server, theDNS query to an authoritative name server; obtaining, from theauthoritative name server, the answer to the DNS request and arespective first time-to-live (“TTL”) value for the answer; determining,at the recursive DNS server, that the first TTL value obtained from theauthoritative name server exceeds a second TTL value provided by theclient for the DNS request; storing, in the memory of the recursive DNSserver, an association between the answer and the second TTL value; andreturning the answer with the second TTL value to the client.

In some aspects, wherein returning the answer with the second TTL value,further comprises providing the answer and the second TTL value to anintermediate DNS server in communication with the client.

In some aspects, the method can further comprise decreasing the secondTTL value in time increments subsequent to the determining that thefirst TTL value obtained from the authoritative name server exceeds thesecond TTL value.

In some aspects, the method can further comprise obtaining a commandfrom the client to flush the memory of the recursive DNS server.

In some aspects, the method can further comprise obtaining, from theclient, a subsequent DNS query for the DNS record; determining, by therecursive DNS server, that the answer to the DNS query is located in thememory; decreasing the second TTL value based on a time differencebetween the DNS query and the subsequent DNS query to produce third TTL;storing the third TTL value; returning the answer to the client with thethird TTL value.

In some aspects, the method can further comprise retrieving a policy forthe client; and returning the answer based on the policy.

In accordance with aspects consistent with the present teachings, amethod for answering a domain name system (“DNS”) request at a recursiveDNS server is provided. The method can comprise obtaining, from aclient, a DNS query for a DNS record; determining, by the recursive DNSserver, that an answer to the DNS request is found in a memory of theDNS recursive server; determining, by the recursive DNS, that atime-to-live (“TTL”) value set by the client is valid; retrieving apolicy for the client; and returning an answer based on the policy andthe TTL value to the client.

In accordance with aspects consistent with the present teachings, adevice for assigning a time-to-live (“TTL”) value for a domain namesystem (“DNS”) record at a recursive DNS server is provided. The devicecan comprise a memory containing instructions; and at least oneprocessor, operably connected to the memory, the executes theinstructions to perform operations comprising: obtaining, from a client,the TTL value for the DNS record; and storing, in a memory of therecursive DNS server, the TLL value, an identifier of the client, andthe DNS record.

In some aspects, wherein the at least one process is further operable toperform the operations comprising obtaining, from the client, a policyto be applied to the DNS record to control how the DNS record isprocessed.

In accordance with aspects consistent with the present teachings, adevice for answering a domain name system (“DNS”) request at a recursiveDNS server is provided. The device can comprise a memory containinginstructions; and at least one processor, operably connected to thememory, the executes the instructions to perform operations comprising:obtaining, from a client, a DNS query for a DNS record; determining, bythe recursive DNS server, that an answer to the DNS request is not foundin a memory of the DNS recursive server; providing, by the recursive DNSserver, the DNS query to an authoritative name server; obtaining, fromthe authoritative name server, the answer to the DNS request and arespective first time-to-live (“TTL”) value for the answer; determining,at the recursive DNS server, that the first TTL value obtained from theauthoritative name server exceeds a second TTL value provided by theclient for the DNS request; storing, in the memory of the recursive DNSserver, an association between the answer and the second TTL value; andreturning the answer with the second TTL value to the client.

In some aspects, wherein returning the answer with the second TTL value,further comprises providing the answer and the second TTL value to anintermediate DNS server in communication with the client. In someaspects, wherein the at least one process is further operable to performthe operations comprising decreasing the second TTL value in timeincrements subsequent to the determining that the first TTL valueobtained from the authoritative name server exceeds the second TTLvalue. In some aspects, wherein the at least one process is furtheroperable to perform the operations comprising obtaining a command fromthe client to flush the memory of the recursive DNS server. In someaspects, wherein the at least one process is further operable to performthe operations comprising: obtaining, from the client, a subsequent DNSquery for the DNS record; determining, by the recursive DNS server, thatthe answer to the DNS query is located in the memory; decreasing thesecond TTL value based on a time difference between the DNS query andthe subsequent DNS query to produce third TTL; storing the third TTLvalue; returning the answer to the client with the third TTL value. Insome aspects, wherein the at least one process is further operable toperform the operations comprising: retrieving a policy for the client;and returning the answer based on the policy.

In accordance with aspects consistent with the present teachings, adevice for answering a domain name system (“DNS”) request at a recursiveDNS server is provided. The device can comprise a memory containinginstructions; and at least one processor, operably connected to thememory, the executes the instructions to perform operations comprising:obtaining, from a client, a DNS query for a DNS record; determining, bythe recursive DNS server, that an answer to the DNS request is found ina memory of the DNS recursive server; determining, by the recursive DNS,that a time-to-live (“TTL”) value set by the client is valid; retrievinga policy for the client; and returning an answer based on the policy andthe TTL value to the client.

In accordance with aspects consistent with the present teachings, acomputer readable medium having instructions to perform a method forassigning a time-to-live (“TTL”) value for a domain name system (“DNS”)record at a recursive DNS server is provided. The method can compriseobtaining, from a client, the TTL value for the DNS record; and storing,in a memory of the recursive DNS server, the TLL value, an identifier ofthe client, and the DNS record.

In accordance with aspects consistent with the present teachings, acomputer readable medium having instructions to perform a method foranswering a domain name system (“DNS”) request at a recursive DNS serveris provided. The method can comprise obtaining, from a client, a DNSquery for a DNS record; determining, by the recursive DNS server, thatan answer to the DNS request is not found in a memory of the DNSrecursive server; providing, by the recursive DNS server, the DNS queryto an authoritative name server; obtaining, from the authoritative nameserver, the answer to the DNS request and a respective firsttime-to-live (“TTL”) value for the answer; determining, at the recursiveDNS server, that the first TTL value obtained from the authoritativename server exceeds a second TTL value provided by the client for theDNS request; storing, in the memory of the recursive DNS server, anassociation between the answer and the second TTL value; and returningthe answer with the second TTL value to the client.

In accordance with aspects consistent with the present teachings, acomputer readable medium method having instructions to perform a methodfor answering a domain name system (“DNS”) request at a recursive DNSserver is provided. The method can comprise obtaining, from a client, aDNS query for a DNS record; determining, by the recursive DNS server,that an answer to the DNS request is found in a memory of the DNSrecursive server; determining, by the recursive DNS, that a time-to-live(“TTL”) value set by the client is valid; retrieving a policy for theclient; and returning an answer based on the policy and the TTL value tothe client.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitutes apart of this specification, illustrates an embodiment of the presentteachings and together with the description, serves to explain theprinciples of the present teachings. In the figures:

FIG. 1 is an exemplary network layout 100 for use with the methods andsystems described herein according to embodiments;

FIG. 2 shows an example DNS process according to embodiments;

FIG. 3 shows an example scenario for maximum time-to-live (“TTL”) withcache flush according to embodiments;

FIG. 4 shows an example scenario for maximum TTL and low TTL accordingto embodiments;

FIG. 5 shows an example scenario for maximum TTL with normal networkflow according to embodiments;

FIG. 6 shows an example scenario for maximum TTL and low TTL with ahijacked result according to embodiments;

FIG. 7 shows an example scenario for maximum TTL with a hijacked resultaccording to embodiments; and

FIG. 8 shows an example computer system according to embodiments.

It should be noted that some details of the figures have been simplifiedand are drawn to facilitate understanding of the embodiments rather thanto maintain strict structural accuracy, detail, and scale.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the presentteachings, examples of which are illustrated in the accompanyingdrawings. In the drawings, like reference numerals have been usedthroughout to designate identical elements, where convenient. In thefollowing description, reference is made to the accompanying drawingsthat form a part of the description, and in which is shown by way ofillustration one or more specific example embodiments in which thepresent teachings may be practiced.

Further, notwithstanding that the numerical ranges and parameterssetting forth the broad scope of the disclosure are approximations, thenumerical values set forth in the specific examples are reported asprecisely as possible. Any numerical value, however, inherently containscertain errors necessarily resulting from the standard deviation foundin their respective testing measurements. Moreover, all ranges disclosedherein are to be understood to encompass any and all sub-ranges subsumedtherein.

Generally speaking, aspects consistent with the present disclosure allowa user of a Recursive Service to set a maximum TTL on any record thatthey receive. In this case, if a record has been misconfigured orhijacked on the authoritative server, the exposure to such a bad recordwill be reduced when the maximum TTL is set to a lower value. This,coupled with the Recursive Service’s cache flush feature, will provide amechanism for quickly removing invalid records from an entireorganization. This allows for a greatly reduced operational burden inthe face of invalid DNS records. In many cases, this will reduce anorganization’s exposure dramatically even if they are unaware of anissue. In some aspects, a mechanism is provided for configuring amaximum TTL value returned for any DNS record, which can be applied by aconfigured set of source IPs to differentiate the service amongcustomers/users.

FIG. 1 is an exemplary network layout 100 for use with the methods andsystems described herein. User device or client 110 may represent anytype of device that connects to Network 130; for example, a personalcomputer, tablet PC, cellular telephone, Personal Digital Assistant(PDA), and the like. User device 110 has a connection with at least oneIntermediate DNS resolver 115 (also called “Intermediate DNS nameserver” or “Internal Forwarder”) through either a wired, wireless, orother type of network connection. In some embodiments, intermediate DNSresolver 115 may be part of User device 110; in other embodiments, DNSresolver 102 may be a separate device, and may also be located in thesame location or in a different location as User device 110. In theembodiment where the intermediate DNS Resolver 115 is part of the Userdevice 110, shown by dotted line in FIG. 1 , the intermediate DNSresolver 155 can be a DNS service provided as a stub resolver, and/or atan application, operating system, or other software layer on the Userdevice 110. In the embodiment where the intermediate DNS resolver 115 isa separate device, the intermediate DNS resolver 115 can be one or moreintermediate DNS resolvers, such as an internal server within acorporate intranet or part of an internet service provide (“ISP”). Eachof the one or more intermediate DNS resolver 115 includes one or moredata caches, such as cache 145, for storing DNS records 150. Forexample, cache 145 contains records of client IP addresses andassociated maximum TTL values as set by an operator of the IP address.

User device 110 and intermediate DNS resolver 115 has a connection withRecursive DNS Server 120 through either a wired, wireless, or other typeof network connection to network 130. Recursive DNS server 120 cancomprise, among other things, administration interface 105, policy agent114, and cache 140. Administration interface 105 allows users a portalwith which they can log into recursive DNS server 120 and manage one ormore domains, records, IP addresses, or other parameters. Administrationinterface 105 also allows users the ability to select or provide one ormore policy through policy agent 114 related to the one or more domains,records, IP addresses, or other parameters. Administration interface 105can also allow user to select or choose a maximum TTL value to beassociated with a particular IP address, which can then be stored incache 140 and be used with policy agent 114 in communicating with Userdevice or client 110.

Recursive DNS server 120 has a connection with authoritative DNS server125 using network 130 through either a wired, wireless, or other type ofnetwork connection to network 130 or another network. Authoritative DNSserver 125 comprises, among other things, a database storing one or morezone files 135. In some embodiments, network 130 can be the Internet,though it may also be another similar network. In some embodiments, userdevice 110 may connect to network 130 independently of intermediate DNSresolver 115; in other embodiments, user device 110 may connect tonetwork 130 through the same connection as intermediate DNS resolver115.

FIG. 2 shows an example DNS process according to embodiments. At 205, auser at a client device logs into an administrative portal or interface105 of the recursive name server and sets a maximum TTL value for asource IP, which is stored, at 210, in a domain record at the recursiveDNS name server 120. The TTL for the source (TTL_(source)) willtypically be less than the TTL maintained at the authoritative DNS nameserver 125 (TTL_(auth)). For example, the user sets the maximumTTL_(source) = 300 seconds. At a later time, the user enters into abrowser at the client device 110 a destination domain name at 215. Ifthe corresponding IP address of the domain name is not found in thecache of the client device 110 (i.e., in the stub resolver), the cacheof an intermediate DNS name server 115 (i.e., an internal network nameserver or an ISP in an exterior network) at 220, the domain name requestis forwarded through the intermediate layers to the authoritative DNSname server 125 at 225. The authoritative DNS name server 125 locatesthe corresponding IP address for the requested domain name and returnsthe domain record to the recursive DNS name server 120 with a TTL valuemaintained at the authoritative DNS name server 125 at 230. Upon therecursive DNS name server 120 receiving the domain record with the IPaddress and the TTL value of the authoritative DNS name server 125, forexample TTL_(auth) = 1000 seconds, the recursive DNS name server 120determines whether or not the source IP that requested the IP addresshas previously set a maximum TTL that it is willing to receive. In thiscase, the source IP has set a maximum TTL_(source) = 300 seconds. Therecursive DNS name server 120, then stores the answer in cache andreturns the IP address with the TTL_(source) = 300 seconds to theintermediate DNS name server 115 that requested the IP address at 235.After this, the value of the TTL_(source) at the recursive DNS nameserver 120 begins to decrement in intervals of seconds (or sub-secondintervals) until the value reaches zero and the recursive DNS nameserver 120 must then forward any DNS queries for which the tTTL hasexpired to the authoritative DNS name server 125. The intermediate DNSname server 125 receive the IP address with the TTL_(source) = 300seconds from the recursive DNS name server 120 and then stores thisanswer in cache and returns it to the client device 110 at 240. As thewith the recursive DNS name server 120, the value of the TTL_(source)begins to decrement in intervals of seconds (or sub-second intervals).

At a subsequent time, for example 100 seconds after the initial DNSrequest by the client device 100, the client device 110 sends anotherDNS request for the domain name that was previously requested at 245.The request is first received at the cache of stub resolver at theclient device 110 or intermediate DNS server 115, where the TTL_(source)now equals 200 seconds (100 seconds from the initial request). The stubresolver or the intermediate DNS server 115 then returns the IP addresswith the TTL_(source) = 200 seconds at 250.

FIGS. 3-7 will be discussed below with regard to client stub resolver305, internal forwarder(s) 310, recursive resolver 315, andauthoritative server 320. FIG. 3 show a scenario for max TTL cache flushaccording to embodiments. In the scenario depicted in FIG. 3 , internalforwarder(s) 310 maintains a cache having a long duration. At 325,client stub resolver 305 sends a flush cache command to recursiveresolver 315. Subsequent to receiving the command, recursive resolver315 flushes its cache. At 330, client stub resolver 305 sends a DNSquery for domain example.com to internal forwarder(s) 310. Because, inthis instance, internal forwarder(s) 310 maintain a cache having a longduration and the cache flush command was not received by internalforwarder(s) 310, internal forwarder(s) 310 returns an answer to the DNSquery to client stub resolver 305 that is likely corrupt or has beenhijacked.

FIG. 4 shows a scenario for max TTL low TTL according to embodiments. At405, client stub resolver 305 sends a DNS query for domain example.comto internal forwarder(s) 310. In this example, internal forwarder(s) 310do not have the answer for the DNS query in its cache. At 410, internalforwarder(s) forwards the DNS query to recursive resolver 315. Again inthis example, recursive resolver 315 does not have the answer for theDNS query in its cache. At 415, recursive resolver 315 forwards the DNSquery to authoritative server 320. At 420, authoritative server 320returns an answer to the DNS query to recursive server 315, where theanswer is cached with recursive resolver 315 for a short duration. At425, recursive resolver 315 forwards the answer to internal forwarder(s)310, where the answer is cached with internal forwarder(s) 310 for ashort duration, which may be same time length of the recursive resolver315. At 430, internal forwarder(s) 310 returns the answer to client stubresolver 305.

FIG. 5 shows a scenario for max TTL normal flow according toembodiments. At 505, client stub resolver 305 sends a DNS query fordomain example.com to internal forwarder(s) 310. In this example,internal forwarder(s) 310 do not have the answer for the DNS query inits cache. At 510, internal forwarder(s) forwards the DNS query torecursive resolver 315. Again in this example, recursive resolver 315does not have the answer for the DNS query in its cache. At 515,recursive resolver 315 forwards the DNS query to authoritative server320. At 520, authoritative server 320 returns an answer to the DNS queryto recursive server 315, where the answer is cached with recursiveresolver 315. At 525, recursive resolver 315 forwards the answer tointernal forwarder(s) 310, where the answer is cached with internalforwarder(s) 310, which may be the same time length of the recursiveresolver 315. At 530, internal forwarder(s) 310 returns the answer toclient stub resolver 305.

FIG. 6 shows a scenario for max TTL low TTL hijacked according toembodiments. At 605, client stub resolver 305 sends a DNS query fordomain example.com to internal forwarder(s) 310. In this example,internal forwarder(s) 310 do not have the answer for the DNS query inits cache. At 610, internal forwarder(s) forwards the DNS query torecursive resolver 315. Again in this example, recursive resolver 315does not have the answer for the DNS query in its cache. At 615,recursive resolver 315 forwards the DNS query to authoritative server320. At 620, authoritative server 320 returns an answer that has beencorrupted or hijacked to the DNS query to recursive server 315, wherethe answer is cached with recursive resolver 315 for a short duration.At 625, recursive resolver 315 forwards the corrupted or hijacked answerto internal forwarder(s) 310, where the answer is cached with internalforwarder(s) 310 for a short duration, which may be the same time lengthof the recursive resolver 315. At 630, internal forwarder(s) 310 returnsthe answer to client stub resolver 305. At 635, client stub resolver 305sends a flush cache command to internal forwarder(s) 310 and recursiveresolver 315, where their respective caches are flushed. At 640, clientstub resolver 305 sends another DNS query for domain example.com tointernal forwarder(s).

FIG. 7 shows a scenario for max TTL hijacked according to embodiments.At 705, client stub resolver 305 sends a DNS query for domainexample.com to internal forwarder(s) 310. In this example, internalforwarder(s) 310 do not have the answer for the DNS query in its cache.At 710, internal forwarder(s) forwards the DNS query to recursiveresolver 315. Again in this example, recursive resolver 315 does nothave the answer for the DNS query in its cache. At 715, recursiveresolver 315 forwards the DNS query to authoritative server 320. At 720,authoritative server 320 returns an answer that has been corrupted orhijacked to the DNS query to recursive server 315, where the answer iscached with recursive resolver 315. At 725, recursive resolver 315forwards the corrupted or hijacked answer to internal forwarder(s) 310,where the answer is cached with internal forwarder(s) 310, which may besame time length of the recursive resolver 315. At 730, internalforwarder(s) 310 returns the corrupted or hijacked answer to client stubresolver 305.

The foregoing description is illustrative, and variations inconfiguration and implementation can occur to persons skilled in theart. For instance, the various illustrative logics, logical blocks,modules, and circuits described in connection with the embodimentsdisclosed herein can be implemented or performed with a general purposeprocessor, a digital signal processor (DSP), an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA) orother programmable logic device, discrete gate or transistor logic,discrete hardware components, or any combination thereof designed toperform the functions described herein. A general-purpose processor canbe a microprocessor, but, in the alternative, the processor can be anyconventional processor, controller, microcontroller, or state machine. Aprocessor can also be implemented as a combination of computing devices,e.g., a combination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration.

In one or more exemplary embodiments, the functions described can beimplemented in hardware, software, firmware, or any combination thereof.For a software implementation, the techniques described herein can beimplemented with modules (e.g., procedures, functions, subprograms,programs, routines, subroutines, modules, software packages, classes,and so on) that perform the functions described herein. A module can becoupled to another module or a hardware circuit by passing and/orreceiving information, data, arguments, parameters, or memory contents.Information, arguments, parameters, data, or the like can be passed,forwarded, or transmitted using any suitable means including memorysharing, message passing, token passing, network transmission, and thelike. The software codes can be stored in memory units and executed byprocessors. The memory unit can be implemented within the processor orexternal to the processor, in which case it can be communicativelycoupled to the processor via various means as is known in the art.

For example, FIG. 8 illustrates an example of a hardware configurationfor a computer device 800, that can be used to perform one or more ofthe processes described above. While FIG. 8 illustrates variouscomponents contained in the computer device 800, FIG. 8 illustrates oneexample of a computer device and additional components can be added andexisting components can be removed.

The computer device 800 can be any type of computer devices, such asdesktops, laptops, servers, etc., or mobile devices, such as smarttelephones, tablet computers, cellular telephones, personal digitalassistants, etc. As illustrated in FIG. 8 , the computer device 800 caninclude one or more processors 802 of varying core configurations andclock frequencies. The computer device 800 can also include one or morememory devices 804 that serve as a main memory during the operation ofthe computer device 800. For example, during operation, a copy of thesoftware that supports the DNS operations can be stored in the one ormore memory devices 804. The computer device 800 can also include one ormore peripheral interfaces 806, such as keyboards, mice, touchpads,computer screens, touchscreens, etc., for enabling human interactionwith and manipulation of the computer device 800.

The computer device 800 can also include one or more network interfaces808 for communicating via one or more networks, such as Ethernetadapters, wireless transceivers, or serial network components, forcommunicating over wired or wireless media using protocols. The computerdevice 800 can also include one or more storage device 810 of varyingphysical dimensions and storage capacities, such as flash drives, harddrives, random access memory, etc., for storing data, such as images,files, and program instructions for execution by the one or moreprocessors 802.

Additionally, the computer device 800 can include one or more softwareprograms 812 that enable the functionality described above. The one ormore software programs 812 can include instructions that cause the oneor more processors 802 to perform the processes described herein. Copiesof the one or more software programs 812 can be stored in the one ormore memory devices 804 and/or on in the one or more storage devices810. Likewise, the data, for example, DNS records, utilized by one ormore software programs 812 can be stored in the one or more memorydevices 804 and/or on in the one or more storage devices 810.

In implementations, the computer device 800 can communicate with otherdevices via a network 816. The other devices can be any types of devicesas described above. The network 816 can be any type of network, such asa local area network, a wide-area network, a virtual private network,the Internet, an intranet, an extranet, a public switched telephonenetwork, an infrared network, a wireless network, and any combinationthereof. The network 816 can support communications using any of avariety of commercially-available protocols, such as TCP/IP, UDP, OSI,FTP, UPnP, NFS, CIFS, AppleTalk, and the like. The network 816 can be,for example, a local area network, a wide-area network, a virtualprivate network, the Internet, an intranet, an extranet, a publicswitched telephone network, an infrared network, a wireless network, andany combination thereof.

The computer device 800 can include a variety of data stores and othermemory and storage media as discussed above. These can reside in avariety of locations, such as on a storage medium local to (and/orresident in) one or more of the computers or remote from any or all ofthe computers across the network. In some implementations, informationcan reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers, or other network devices may bestored locally and/or remotely, as appropriate.

In implementations, the components of the computer device 800 asdescribed above need not be enclosed within a single enclosure or evenlocated in close proximity to one another. Those skilled in the art willappreciate that the above-described componentry are examples only, asthe computer device 800 can include any type of hardware componentry,including any necessary accompanying firmware or software, forperforming the disclosed implementations. The computer device 800 canalso be implemented in part or in whole by electronic circuit componentsor processors, such as application-specific integrated circuits (ASICs)or field-programmable gate arrays (FPGAs).

If implemented in software, the functions can be stored on ortransmitted over a computer-readable medium as one or more instructionsor code. Computer-readable media includes both tangible, non-transitorycomputer storage media and communication media including any medium thatfacilitates transfer of a computer program from one place to another. Astorage media can be any available tangible, non-transitory media thatcan be accessed by a computer. By way of example, and not limitation,such tangible, non-transitory computer-readable media can comprise RAM,ROM, flash memory, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othermedium that can be used to carry or store desired program code in theform of instructions or data structures and that can be accessed by acomputer. Disk and disc, as used herein, includes CD, laser disc,optical disc, DVD, floppy disk and Blu-ray disc where disks usuallyreproduce data magnetically, while discs reproduce data optically withlasers. Also, any connection is properly termed a computer-readablemedium. For example, if the software is transmitted from a website,server, or other remote source using a coaxial cable, fiber optic cable,twisted pair, digital subscriber line (DSL), or wireless technologiessuch as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, or wireless technologies such asinfrared, radio, and microwave are included in the definition of medium.Combinations of the above should also be included within the scope ofcomputer-readable media.

While the teachings have been described with reference to examples ofthe implementations thereof, those skilled in the art will be able tomake various modifications to the described implementations withoutdeparting from the true spirit and scope. The terms and descriptionsused herein are set forth by way of illustration only and are not meantas limitations. In particular, although the processes have beendescribed by examples, the stages of the processes can be performed in adifferent order than illustrated or simultaneously. Furthermore, to theextent that the terms “including”, “includes”, “having”, “has”, “with”,or variants thereof are used in the detailed description, such terms areintended to be inclusive in a manner similar to the term “comprising.”As used herein, the terms “one or more of” and “at least one of” withrespect to a listing of items such as, for example, A and B, means Aalone, B alone, or A and B. Further, unless specified otherwise, theterm “set” should be interpreted as “one or more.” Also, the term“couple” or “couples” is intended to mean either an indirect or directconnection. Thus, if a first device couples to a second device, thatconnection can be through a direct connection, or through an indirectconnection via other devices, components, and connections..

What is claimed is:
 1. A method for assigning a time-to-live (“TTL”)value for a domain name system (“DNS”) record, the method comprising:receiving a policy associated with a given DNS parameter, wherein thepolicy specifies a maximum TTL value for one or more DNS records thatsatisfy the given DNS parameter; transmitting a first DNS requestassociated with a first domain name to an authoritative name server;receiving, from the authoritative name server and in response to thefirst DNS request, (i) a first DNS record associated with the firstdomain name and (ii) a TTL value corresponding to the first DNS record;determining that the policy applies to the first DNS request;determining that the TTL value is greater than the maximum TTL valuespecified by the policy; and storing, in a memory, an associationbetween the maximum TTL value and the first DNS record based on thepolicy.